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(54) Method for transmitting data via a network 

(57) A communication controller (205) at the send- 
ing computer (201) divides data transferred from a host 
(101) into sub-ACK unit packets, and transfers them 
sequentially to a destination without waiting for the sub- 
ACK's being subsequently provided by the destination. 
A communication controller (206) at the receiving com- 
puter (202) issues a sub-ACK to the sencfing computer 
(201) for each of the sub-ACK unit packet, if the sub- 
ACK packet has been normally received and othenvise 
issues retransmission request for the sub-ACK unit 
packets and merges data included in the sub-ACK unit 
packets into the initial data, after they are normally 
received. 



FIG. 2 



-201 



203 

S 



DATA 




^202 



DATA 



OMDEDOATA 


'OIVHJGDOATA 


' D(VH)ED DATA 


DESnWlOWID 


DSTWTPNID 


reSTWATO ID 


i.'.^yv;i:M 






OMSGNOOUNT 


DMaONCOUKT 


DMSIONOOUMT 


OtVBXWID 


DMSCND 


OMSXMIO 


IRNEUSSCNTIE 


ITWaeSONTIE 





.209 

.210 
.211 
212 
.213 
.214 
.215 



208 



208 



208 



Pnmadby Rank Xaroi (UK) Business Services 
2.13.1&9.4 



BNSOOCIO: <EP 07e2705A2_l_> 



1 EP 0 762 705 A2 2 



Description 

BACKGROUND OF THE INVENTION 

The present invention relates to a method tor trans- 
mitting data at high speed via a network and. more par- 
ticularly, to a metiiod for transmitting large quantities of 
data over long distances via a network. 

Where computers can transmit data between them, 
they enjoy the advantage of sharing data. A plurality of 
computers may share one or more files therebetween 
by way of the file server. These functions are all imple- 
mented through the avaiiabifity of data transmission 
between computers or between any one of the config- 
ured computers and a file server. 

Data is transmitted generally via a network con- 
nected to a communication controller included in a com- 
puter. The communication controller is usually furnished 
on a single board. In operation, the communication con- 
troller receives a data transmission request or a data 
reception request from a computer and exchanges data 
with a communication target in units called packets. 
Each packet, which is the unit of data communication, 
contains user data and control information including 
destination and other Information. The communication 
controller is incorporated in the host and is directiy con- 
nected to an internal bus thereof. The host has a pro- 
gram called the operating system working therein. The 
operating system includes communication control soft- 
ware that controls the communication controller. 

A typical network is what is known as the Fibre 
Channel. As discussed in Tibre Channel Connection to 
the Future" (Fibre Channel Association, 1994, pp. 11- 
19). the Fibre Channel is available for communication 
between computers as well as between a computer and 
disk drives. The Fibre Channel is controlled functionally 
by layers FCO through FC4 for each function of tiie fiber 
channel. Of these layers, FCO defines the electrical 
charactaistics of physical cables. FCl stipulates the 
methods for encoding and decoding data, and FC2 
specifies the data format relevant to the Fibre Channel. 
FC3 and FC4 designate logical communication meth- 
ods. The Fibre Channel can connect a plurality of 
devices of different types, the capability being imple- 
mented by the layer FC4 converting data in format for 
use by a plurality of devices on the Fibre Channel. Illus- 
tratively, tiie Ftore Channel may be connected to disk 
drives as well as network devices. FC3 is the layer that 
provides common control over data communication. 
FCO through FC4 are generally implemented by hard- 
ware, specifically on a board comprising a plurality of 
LSrs. With the Fibre Channel, the above-mentioned 
communication control software is a program that con- 
trols disk drives and networks. In operation, the commu- 
nication control program issues requests to FC4 of the 
Fibre Channel. Upon receipt of a request from the com- 
munication control program, the Fibre Channel converts 
the data to its own data format in accordance with the 
FC4 provisions, forwards the data after conversion 



through the layers FC3, FC2, FCl and FCO, in that 
order, and sends to the destination device. Apart from 
the packets mentioned earlier, the Rbre Channel is 
capable of transfen-ing data up to 2 KB long each as 

5 stipulated by FC2. On the Fibre Channel, any data 
exceeding the 2 KB length limit is divided into units of 2 
KB each when transferred by the layer FC2 . 

The communication control software may be func- 
tionally divided into two major layers: a protocol 

10 processing program and a device control program. The 
protocol processing program receives data communica- 
tion requests from a user program. For data transmis- 
sion, the protocol processing program converts user 
data into packets according to the communication proto- 

15 col specific to the network. For data reception, the pro- 
tocol processing program extracts the user data from 
the transmitted packets. The device control program Is a 
program tiiat requests the communication controller to 
transmit packets. The primary function of the device 

20 control program Is to confrol tiie hardware of the com- 
munication controller. In transmitting data, the device 
control program typically executes the following instruc- 
tion string: 

25 (1 ) get_register (STATUS) 

(2) set_register (buf_addr) 

(3) set_register (pktjength) 

(4) set_register (IN, DMA_GO) 

30 The instruction (1) above reads the status of the 
communication controller and checks to see if the status 
is normal. The instruction (2) transmits the location of 
target data in the host to the communication controller. 
The instruction (3) notifies the communication controller 

35 of the length of the packet to be transmitted. The 
instruction (4) starts the hardware for transmitting the 
data from the host to the communication controller. The 
processing above allows the communication controller 
to analyze control information held in the packet and to 

40 transmit the target data to the destination of communi- 
cation. Thereafter, the protocol processing program 
waits for an acknowledgment (abbreviated to ACK here- 
under) to arrive from the destination indicating that the 
data has been normally b*ansmitted. The above proc- 

45 esses (1) through (4) are can-ied out by writing and 
reading information to and from control registers In the 
communication controller. In like manner, tiie device 
control program typically executes the following instruc- 
tion string upon receiving data: 

50 

(1) get_register (STATUS) 

(2) set_register (buf.addr) 

(3) set_register (pktjength) 

(4) set_register (OUT DMA_GO) 

55 

The instruction (1) above reads the status of the 
communication controller and checks to see if the status 
is normal. The instruction (2) transmits the location of 
target data in the host to the communication controller. 
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The instruction (3) notifies the communication controller 
of the length of the packet to be transnnitted. The 
instruction (4) starts the hardware for transmitting the 
data from the communication controller to the host. 
Thereafter, the protocol processing program generates 5 
an ACK and sends it to the destination of communica- 
tion indicating that the data has been normally transmit- 
ted. The processing above allows the communication 
controller to analyze the control information held in the 
packet and to transmit the target data to the destination 70 
of communication. 

What characterizes the above type of communica- 
tion is that an ACK is transmitted and received to verify 
the normal transfer of data every time a packet has 
been transmitted. With commonly implemented net- is 
works, the packet size is limited to be 1 to 4 kilobytes. To 
transmit data exceeding the size of one packet requires 
dividing the data into a plurality of packets that may be 
transmitted. In such a case, a plurality of ACK's are to 
be transmitted and received regarding each set of user 20 
data divided into a plurality of packets. After one packet 
is transmitted, the next packet cannot be transmitted 
unless and until the ACK for the most recently transmit- 
ted packet has been returned. This prohibition of trans- 
mission of the next packet is for communication. In data 25 
communication, if any packet is not transmitted nor- 
mally the same packet must be retransmitted. This 
requires retaining the most recently transmitted data in 
the memory on the transmitting side in preparation for 
possible retransmission. How long the data should 30 
remain in the memory is determined upon receipt of an 
ACK. That is, when the destination of communication 
has returned an ACK indicating tiie normal reception of 
the data, then the packet retained on the transmitting 
side is discarded. 35 

One disadvantage of the above method of data 
transmission is that it takes time to transmit data. This is 
because the next packet cannot be transmitted until the 
ACK for the cun-ent packet is returned. A solution to this 
problem is described illustratively by Samuel J. Letter et 4o 
al., in "The Design and Implementation of the 4.3BSD 
UNIX Operating System" (Addison -Wesley Publishing 
Company, Inc., 1989, pp. 368-375). The solution 
involves transmitting a plurality of packets sequentially 
In the above-cited reference, the protocol processing 45 
program stipulates that an ACK is to be issued for every 
n packets (i.e., n times the packet size). Within tiiat unit 
of data transmission, packets may be transmitted and 
received sequentially For exanrple, suppose that the 
packet size is 1 KB, that an ACK is issued in units of 10 so 
KB. and that 20 KB of user data are to be transmitted. In 
this case, tiie protocol processing program on the data 
transmitting side initially receives 1 0 KB of data from the 
user program. The protocol processing program divides 
the 10-KB data into 10 packets of 1 KB each. The 10 55 
packets are sent consecutively to the destination. Hav- 
ing transmitted the 10 packets, the transnritting side 
waits for an ACK to be returned by the receiving side. 
The receiving side puts together the packets of 1 KB 



each as they are continuously sent in. When the last 1- 
KB packet has an-ived, the receiving side returns an 
ACK to tiie transmitting side. Upon receipt of tiie ACK. 
tiie transmitting side verifies tiiat all data have been 
transmitted normally If everything is normal, tiie proto- 
col processing program of the transmitting side will per- 
form the same process on the next 10-KB data. If the 10 
packets were not transmitted normally, the same 10 
packets are retransmitted. This method offers better 
data transfer performance than the method desaibed 
earlier because packets can be transmitted consecu- 
tively within, say, the 10-packet range. 

SUMMARY OF THE INVENTION 

When a set of data is transmitted conventionally 
tiie data is divided into packets and an ACK is returned 
every time a packet has been ti'ansmttted and received. 
If no ACK comes back, tiie next packet cannot be trans- 
mitted. The time required to return an ACK depends 
largely on the distance over which the data is transmit- 
ted. The longer tiie transmitting distance, tiie more pro- 
longed the time required to return an ACK. This makes 
it difficult to transmit one packet after another continu- 
ously because an appreciable wait time can occur 
before an ACK arrives following tiie transmission of 
each packet. Where longer fansmitting distances are 
involved, the network usability drops precipitously 
because of tiie prolonged ACK wait time. This impedes 
ttie network from being utilized effectively The problem 
becomes more pronounced with high-speed data trans- 
mission media such as optical fiber cables. That is, tiie 
ability of the media to transmit data rapidly is canceled 
out by the increased time in which ACK's are awaited. 

The solution to tiie problem proposed by the above- 
dted reference increases tiie size of the data for which 
one ACK is returned so tiiat data may be transmitted at 
the high possible speed. More specifically, data items 
each smaller than an enlarged ACK are transmitted 
consecutively By enlarging the ACK. the proposed 
method appears to provide faster data transmission 
than the earlier method. The greater the ACK. the more 
efficient data transmission is supposed to become. 
However, ttie proposed method is effective only if all 
data is transmitted normally. Long-distance communi- 
cation is known to diminish the rate at wNch data is 
transmitted normally to ttie destination, mainly due to 
cable noise and data losses ttirough network relay com- 
puters. Most network relay conoputers are connected to 
a plurality of networks. In such setups, memory con- 
straints in any relay computer can truncate received 
data. The longer the transmitting distance is, the grow- 
ing number of relay computers are installed to repeat 
data within or between networks. Numerous relay com- 
puters are liable to a growing probability of data loss. 
According to the mettiod proposed by the above-cited 
reference, if any data item wrthin a given ACK unit is 
lost, ttie entire ACK unit must be retransmitted. If 
retransmission overhead is taken into consideration in 
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an environment of a high probability of data loss, the 
perfornr^nce of data transfer can be lower than that of 
the earlier method. 

According to the present invention, one ACK unit is 
divided into a plurality of sub-ACK unit packets each fur- 
nished with a tag indicating the pre-division position. 
The divided packets are transmitted sequentially. Upon 
receipt of each divided packet, the receiving side com- 
munication controller returns a sub-ACK comprising the 
result of the reception to the transmitting side communi- 
cation controller. Having received all packets, the 
receiving side communication controller determines the 
order of the packets as per the contents of ther tags 
indicating the pre-division position and merges their 
data parts. The transmitting side checks the received 
sub-ACK's for the result of the reception to see if any 
packet need retransmission. Any packet is retransmitted 
if determined to be necessary. When all sub-ACK's 
have been normally received, the transmitting side puts 
them into a single ACK and notifies the request source 
thereof. 

Because one ACK unit is divided into a plurality of 
sub-ACK unit packets for consecutive transmission, 
data transfer performance is enhanced. Since a packet 
retransmission request may be issued for each sub- 
ACK. drops in the transmitting performance are mini- 
mized in long-distance communication setups. 

Other objects, features and advantages of the 
present invention will become apparent in the following 
specification and accompanying drawings. . 

BRIEF DESCRIPTION OF THE DRAWINGS 

Rg. 1 is an overall block diagram outlining a cohpu- 
ter system which realizes a method for transmitting 
data via a network according to the present inven- 
tion; 

Fig. 2 is a method diagram for explaining the data 
transmission according to the present invention; 
Rg. 3 is another diagram explaining the effects of 
the present invention; 

Rg. 4 is a timing chart of the first embodiment; 
Rg. 5 is a timing chart of one conventional method 
for transmitting data via a network; 
Rg. 6 is a timing chart of another conventional 
method for transmitting data via a network; 
Rg. 7 is a flowchart of steps showing how a user 
program of the first embodiment typically works; 
Rg. 8 is a block diagram showing the constitution of 
the operating system of the first embodiment; 
Rg. 9 is a flowchart of steps showing how a consec- 
utive transmission controlling program of the first 
emtxxjiment typically works; 
Rg. 10 is another flowchart of steps also showing 
how the consecutive transmission controlling pro- 
gram typically works; 

Rg. 1 1 is a block diagram depicting the transfer of 
data from a host to a communication controller; 
Rg. 1 2 is a flowchart of steps showing how a packet 



transmitting program of the first embodiment typi- 
cally works; 

Rg. 13 is a schematic view illustrating the structure 
of a transmission destination table: 
5 Rg. 1 4 is a flowchart of steps showing how a packet 
dividing program of the first embodiment typically 
works; 

Rg. 1 5 is a conceptual view depicting the transfer of 
data from the communication controller to a net- 
to work; 

Rg. 16 is a conceptual view indicating the constitu- 
tion of a sub-ACK packet; 
Rg. 17 is a flowchart of steps showing how a sub- 
ACK is received; 
15 Rg. 18 is a conceptual view depicting the constitu- 
tion of an ACK table; 

Rg. 19 is a conceptual view outlining the effects of 
the first embodiment; 

Rg. 20 is a flowchart of steps showing how a packet 
20 receiving program of the first embodiment typically 
works; 

Rg. 21 is a conceptual view indicating how tags are 

removed and data are merged; 

Rg. 22 is a conceptual view sketching how the 

25 invention is applied to a disk drive arrangement; 

Rg. 23 is an overall block diagram of a second 
embodiment of the invention; 
Rg. 24 is a conceptual view portraying the constitu- 
tion of a packet for use with the second embodi- 

30 ment; 

Rg. 25 is a flowchart of steps showing how a 
divided packet transmitting program of the second 
embodiment typically works; 
Rg. 26 is a flowchart of steps showing how a 

35 divided packet receiving program of the second 
embodiment typically works; and 
Rg. 27 is a conceptual view indicating how packets 
are consecutively transmitted in a multiple port 
setup of the second embodiment. 

40 

DESCRIPTION OF THE PREFERRED EMBODI- 
MENTS 

First Embodiment 

45 

Preferred embodiments of the invention will now be 
described in detail with reference to the accompanying 
drawings. 

Rg. 1 is an overall block diagram outlining a compu- 
50 ter system wNch adopts a method for transmitting data 
via a network according to the present invention. In Rg. 
1 , reference numeral 101 is a host and 105 is a commu- 
nication controller. The host 101 comprises a processor 
102 for executing user programs and so on. a host 
55 menrx}ry 1 03 for accomnrKXlating the user program, user 
data. etc.. and a bus 104. The bus 104 is connected to 
a communication controller 105 or the like for communi- 
cating with the processor 102 host menoory 103 and 
outside of the computer. The communication controller 
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105 includes a bus interface 106 that communicates 
with the bus inside the host 101, a control processor 
107 that controls the hardware in the communication 
controller 105, a control memory 108 that stores control 
software to be executed by the control processor 107. a 
communication interface 119 that communicate with 
and a data memory 121 and externally connected 
devices, a comnuinication toad measuring device 120 
that measures the load of the network to which the com- 
munication controller 105 is connected, the data mem- 
ory 121, a data bus 1 17 for data transmission, a control 
bus 118 for transmitting control information, a backup 
device 122 that backs up the contents of the data nrrem- 
ory 121, a transmitter 126, and a receiver 125. The 
transmitter 126 and receiver 125 are connected to an 
external network. The bus interface 106 comprises a 
buffer 115 that temporarily retains data transferred 
between the host memory 103 and the communication 
controller 105. and a DM AC 116 that transfers data 
between the host memory 103 and the communication 
controller 105. The communication interface 119 is 
made up of a buffer 124 that tenporarily holds data 
transferred between the data memory 121 and an exter- 
nally connected device, and a DM AC 123 that transfers 
data between the data memory 121 and the external 
device. The control memory 108 stores control software 
to be executed by the control processor 107, Reference 
numerals 109 and 1 12 denote control software dealing 
with packet transmission and packet reception, respec- 
tively. The packet transmitting program 109 comprises a 
packet dividing program 1 10 and a tag adding program 
1 1 1, etc. The packet receiving program 112 includes a 
packet merging program 113 and a tag removing pro- 
gram 114, etc. 

How the system of Fig. 1 works will now be 
desCTibed by refen-ing to Fig. 2. What is shown in Fig. 2 
is a process of data transmission and reception 
between a host 201 (conresponding to the host 101 in 
Fig. 1) and a host 202 (corresponding to the host 101 in 
Fig. 1), both connected to a network 216. Specifically, 
the host 201 transmits data 203 constituting an ACK 
unit of the host 201. the data 203 being received (as 
data 204) tsy the computer 202. The ACK unit is a unit of 
data for which an ACK must be returned before the next 
packet of data can be transmitted. The conrputers 201 
and 202 are connected to conununication controllers 
205 and 206 respectively. The data 203 sent from the 
computer 201 is divided in the communication controller 
205 into three data 209 each constituting a sub-ACK 
unit. Each divided data 209 is constructed as a packet 
208. 

This setup may be elaborated in connection with 
the Rbre Channel as follows. The Fibre Channel is con- 
nected to disk drives and network devices. An example 
of data communication between computers in the Fibre 
Channel will be explained by reference to Fig. 2. The 
control programs to control the connected devices run 
on the computers 201 and 202. Each of the control pro- 
granrs to control the disk drives and networks issues a 



request for data (corresponding to 203) to the communi- 
cation controller (corresponding to 205) of the Fibre 
Channel. In response, the communication controller 
(205) divides the data (203) into units of up to 2 KB 

5 each, the maximum unit of data transfer by the Fibre 
Channel, to be sent as divided data (209). The divided 
data 209 thus transferred are received by the destina- 
tion comnrujnication controller (corresponding to 206) of 
the Fibre Channel and reconstructed therein as packets 

70 208 for transfer to the computer 202. Specifically, of the 
Fibre Channel layers FCO through FC4, the layer FC4 
takes care of data division control. These arrangements 
nrtake it possible to practice the invention without modi- 
fying the existing control software. 

15 Returning to Fig. 2, besides its user data (i.e., 
divided data) 209, each packet 208 is furnished with 
tags such as a destination ID 210, a flag 21 1 indicating 
a division of the data 203, a packet ID 212, a division 
count 213 (number of divided data), a division ID 214 

20 indicating where the divided data is located in the post- 
division data order, and a transmission time 215 at 
which the packet is transmitted. Upon reception of each 
data, the communication controller 206 removes the 
tags from each packet so as to reconstruct the initial ^ 

25 data 204. During data reconstruction, the communica- 
tion controller 206 refers to the division flag 211. packet 
ID 21 2, division count 21 3 and division ID 21 4 indicating 
the post-division data order. For each packet, the com- 
munication controller 206 returns a sub-ACK 207 indi- 

30 eating completion of data transmission. If any one of the 
three transmitted packets has developed a transmission 
en-or, the oc^rrence of the error is written into the cor- 
respondmg sub-ACK 207. In response, the communica- 
tion controller 205 retransmits only the packet 

35 corresponding to the sub-ACK in question. Where any 
of the divided packets has developed transmission 
* en-br, only the faulty packet is retransmitted; there is no 
need to retransmit all packets 20a When all sub-ACK's 
are normally returned, the three sub-ACK*s are inte- 

40 grated into one ACK and the host 101 is notified of the 
normal completion of data transmission. Because the 
target data is divided into sub-ACK units each furnished 
with a division flag 211. a packet ID 212. a division 
count 213 and a division ID 214 indicating the post-divi- \ 

45 sion data order, the divided data are transmitted and 
received as an independent packet each through paral- 
lel packet transmission. The sub-ACK' are merged into 
one ACK which is then transferred to the source of the 
request. The procedure here is equivalent to conven- ^ 

so tional communication protocol and contrtoutes to mini- 
mizing the amount of changes needed in the software of 
the host where the invention is applied. Details of the 
hardware and software of the above setup will be 
described later. 

55 Rg. 3 is a diagram for showing effects of the 
present invention. As with the setup of Fig. 2. the exam- 
ple of Rg. 3 divides an ACK unit of user data into three 
sub-ACK units (319) for consecutive packet transmis- 
sion. Specifically, a communication controller 302 trans- 
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fers user data 301 to be received by another 
communication controller 317. The communication con- 
troller 302 divides the data 301 into three packets each 
furnished with tags. The packets are outputted consec- 
utively onto a transmission path 306 (308 through 310). 
Packets 31 1 through 313 denote packets which include 
divided data of user data that were outputted earlier 
than the user data 301. The communication controller 
317 removes tags from the packets 311 to 313 which 
include the previously outputted user data to recon- 
struct the initial data user (318). For the packets 311 
through 313, the communication controller 317 returns 
sub-ACK's 314 through 316 respectively. When all sub- 
ACK units have been returned, the sub-ACK's are 
merged into one ACK (320) which is sent to the source 
of the request. Unlike the conventional arrangement in 
which the next packet cannot be transmitted until an 
ACK is returned for the cun-ent packet, the embodiment 
of the invention waits for the return of an ACK only 
between the packets 308 through 310 on the one hand, 
and the packets 311 through 313 on the other The 
result is data transmission at an enhanced speed. 
Because the sub-ACK's are returned over a path differ- 
ent from the transmission path, there is no possibility of 
collision between the data and sub-ACK's. This is 
another advantage of the invention. 

Fig. 4 is a timing chart showing the flow of control of 
the first embodiment. Fig. 4 depicts an example in which 
a host 401 transfers data 405 to another host 405. The 
user data 405 sent from the host 401 to a communica- 
tion controller 402 is divided by the latter into a plurality 
of sub- ACK units (408 through 41 1) which are transmit- 
ted consecutively to the destination. Upon receiving the 
data, a communication controller 403 returns a sub- 
ACK for each of the divided sub- ACK unit packets (412 
through 414). The communication controller 403 further 
merges the divided packets for data transfer to the host 
(407). Meanwhile, the communication controller 402 
receives a plurality of sub-ACK's and merges them into 
one ACK which is returned to the host. In this manner, 
the user data is divided and transmitted in units of sub- 
ACK's. each data division being transmittable independ- 
ently, whereby the data transfer performance is 
improved. 

Below is a comparison of the first emtxxjiment with 
typical prior art communication methods whose work- 
ings are illustrated in Figs. 5 and 6. Fig. 5 shows a con- 
ventional method wherein an ACK is returned for each 
of the packets (505, 507) transmitted by a host 501 . 
According to the method of Fig. 5. hosts 501 and 504 or 
communication controllers 502 and 503 transmit data 
and ACK for each data transfer request from a user pro- 
gram. Because it takes time before each ACK is 
returned with this method, a prolonged time period is 
required before a succeeding packet is transmitted. Fig. 
6 depicts another conventional method which improves 
transfer performance by dividing a set of user data into 
a plurality of packets and by transmitting those packets. 
According to the method of Fig. 6, a data receiving com- 



munication control board 603 returns only one ACK for 
the entire set of user data (605 or 607). This means that 
if any one of the divided packets has developed trans- 
mission eror, all packets need to be retransmitted. 

5 Where long communication distances are involved, the 
conventonal method is subject to a growing probability 
of data losses and can diminish the performance of data 
transfer instead of improving it. These pitfalls are cir- 
cumvented by the first embodiment of the invention 

70 using sut^ACK units. The sub- ACK units make it possi- 
ble to verify which of the divided packets has developed 
an error. Therefore, even transmission data over long 
distances requires small amount of data to be retrans- 
mitted and thus enjoy higher speeds of data transfer. 

75 How the first embodiment works will now be 
described in more detail by referring to the accompany- 
ing drawings from Fig. 7 on. Fig. 7 shows an example of 
user programs. This is an example of data communica- 
tion between the user program on the transmitting side 

20 (701 through 703) and the user program on the receiv- 
ing side (704 through 706). Steps 701 and 704 define 
the environment necessary for communication. At this 
point, communication is yet to take place between the 
two programs. Steps 702 and 705 check to see if a com- 

25 munication target and is ready to communicate. Step 
703 transmits user data to the communication target 
checked in step 702. There is no need for the user pro- 
gram to become aware of the packet size in effect. That 
is, there are no concept of a packet size or an ACK unit 

30 to be taken into account at this stage of communication. 
The packet size and ACK unit are concepts defined by 
the operating system 2403, to be described later. 

Rg. 8 shows the constitution of the programs in a 
host memory 2401 (corresponding to the host memory 

35 1 03 in Rg. 1 ). When a user program 2402 issues a com- 
munication request, a processing request is transferred 
to the operating system 2403. The communication 
processing is carried out by a packet transmitting pro- 
gram 2404 and a packet receiving program 2405 inside 

40 the operating system 2405. The packet transmitting pro- 
gram 2404 and packet receiving program 2405 are 
known programs that define ACK units. Whereas the 
conventional system has a communication controller 
2408 (corresponding to the communication controller 

45 105 of Rg. 1 ) directiy controlled by the packet transmit- 
ting program 2404 and packet receiving program 2405, 
the first embodiment of tiie invention has its packet 
transmitting program 2404 connected to a consecutive 
transmission controlling program 2406 and a transmis- 

50 sion incomplete data buffer 2407. The consecutive 
transmission controlling program 2406 is capable of 
enlarging the ACK unit of tiie packet transmitting pro- 
gram 2404. Details of the consecutive transmission con- 
trolling program 2406 and transmission incomplete data 

55 buffer 2407 will be described next. 

Rg. 9 is a flowchart of the consecutive transmission 
controlling program 2406 of the host at data transmis- 
sion. The consecutive fransmission controlling program 
2406 is called up by the packet transmitting program 
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2404 of Fig. 8. Step 2501. temporarily places in the 
transmission incomplete data buffer 2407 the data for 
which a transmission request has been issued by the 
packet transmitting program 2404. Step 2502 issues a 
transmission request to the communication controller 
2408. Details of this step will be described later The 
consecutive transmission controlling program 2406 noti- 
fies the packet transmitting program 2404 is notified of 
the completion of data transmission at this moment by 
the step 2503. This allows the packet transmitting pro- 
gram 2404 to regard as if the ACK has been returned for 
the transmitted data, and to request transmission o1 the 
next data. If more data to be transmitted is found to exist 
in step 2504, the process starting from the step 2501 is 
again repeated. The transmission incomplete data 
buffer 2407 retains its contents until the transmission is 
normally completed, in preparation for possible retrans- 
mission of lost packet data. Whereas the procedure of 
data retention is performed traditionally by the packet 
transmitting program 2404. the program 2404 here dis- 
cards the data because the process is considered nor- 
mally taminated by the step 2503. 

Fig. 10 is a flowchart of the consecutive transmis- 
sion controlling program 2406 at reception. In step 
2601. an ACK is received from the transmitting side. In 
step 2602. a check is made to see if all user data has 
been transmitted. If the transmission is normal, the 
applicable data in the transmission incomplete data 
buffer 2407 is erased therefrom in step 2603. The proc- 
esses of Figs. 9 and 10 allow the ACK unit to be 
enlarged without modifying the existing programs. This 
is another advantage of the present invention. 

Fig. 11 is a block diagram depicting how data is 
transmitted from a host 801 (corresponding to the host 
101 of Fig. 1) to a communication controller 802 (corre- 
sponding to the communication controller 105 of Fig. 1). 
Reference numeral 803 points to details of the process- 
ing of step 2502 carried out by the consecutive trans- 
mission controlling program 2406. 

(1) get_register (STATUS) 

In this processing, the status of the communication 
controller 802 is acquired. When the status is found to 
be normal, the transmission processing continues. 

(2) set_register (buf_addr) 

In this processing, the start address of the transfer 
target data in the host 801 is written into one of a group 
of control registers (807 through 810) in the communi- 
cation controller 802. 

(3) set_register (pktjength) 

In this processing, the length of the transfer data in 
the host 801 is written into one register of the control 
register group (807 through 810) in the communication 
controller 802. 
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(4) set_register (IN. DMA_GO) 

In this processing, an instruction issued to the 
DMAC116of Fig, 1 fbrdatatransfertoabuffer 811. The 
5 transferred data has the start address and the length 
both held in the control registers. The data in the host 
801 is in packet format and comprises control informa- 
tion 804 such as the destination ID in addition to the 
user data 805. 

10 Rg. 1 2 is a flowchart of the packet transmitting pro- 
gram 109 of the communication controller 105 of Fig. 1 . 
In step 901 , the data placed into the buffer 81 1 by the 
processing shown in Fig. 1 1 is transferred to the data 
memory 121. Following step 901, the communication 

15 controller 107 can control the data. In step 902, the 
packet data is divided into sub-ACK unit packets by the 
packet transmitting program 109 in accordance with a 
division unit. How the division unit is determined will be 
described later with reference to Fig. 14. In step 903, 

20 each of the sub-ACK unit packets derived through divi- 
sion from the packet data is furnished with tags 209 
through 215 in Fig. 2. In step 904, the sub-ACK unit 
packets are transmitted to the destination. In this step, 
the control processor 107 transfers the packets to a 

25 buffer 124 of Fig. 1 via a communication interface 1 1 9 of 
Fig. 1 by use of a data transfer device 123 of Fig. 1. 
Then, the transmitter 126 transmits the sub-ACK unit 
packets according to the relevant protocol. In step 905. 
a check is made to see if all sub-ACK unit packets have 

30 been transmitted. If any sub-ACK unit packet has yet to 
be transmitted, step 904 is reached again and the 
packet in question is retransmitted. In steps 906, 909 
and 907, sub-ACK's are awaited for all divided packets 
transmitted. After these steps have verified the sub- 

35 ACK's for all normally transmitted packets in sub-ACK 
units, it becomes possible to merge the sub-ACK's. If 
any sub-ACK indicates an abnormally transmitted 
packet, only the packet in question is retransmitted in 
step 909. When the sub-ACK's have been received from 

40 the destination indicating that all divided packets have 
been normally transmitted, the sub-ACK's are merged. 
In step 908, the packet transmitting program 109 noti- 
fies the host of the completion of data transfer. 

How a packet is divided in step 902 of Fig. 12 will 

45 now be described in more detail with reference to Figs. 
13 and 14. Fig. 13 is a schematic view illustrating the 
structure of a transmission destination table which is 
held in the control memory 108. is controlled by the 
communication controller 105, and accommodates 

so information for use upon packet division. In the table, 
column 1001 holds destination ID'S representing previ- 
ously accessed transmission destinations. New destina- 
tions may be added to the table. Column 1002 retains 
units of division. Different destinations have different 

55 distances to cover and need to be assigned an optimum 
division unit each. Column 1003 stores the response 
time registered when each destination was most 
recently accessed. The response time is the time 
required to send data of a specific length. Column 1004 
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holds the communication loads specif ic to the destina- 
tions. Column 1005 accommodates the direction of divi- 
sion for each destination. The direction of division 
indicates whether the current unit of division is to be 
enlarged or reduced. An indication "+1" means that the 
division unit is to be enlarged and "-r means the divi- 
sion is to be reduced. Every time data is transferred, the 
response time column 1003 and communication load 
column 1004 are referenced and the division unit is 
updated in such a manner that the data transfer per- 
formance will be improved. Details of this process wilt 
be described later with reference to Fig. 1 4. The division 
unit is dynamically changed upon every access so that 
an optimum division unit will be gradually approximated. 
The transmission destination table Is stored in the data 
memory 121 and backed up by the backup device 122. 
Thus the table is preserved unless and until the user for- 
cibly resets the table contents. The use of the transmis- 
sion destination table permits data transfer of constantly 
optimum performance. 

Rg. 1 4 is a flowchart of tine packet dividing step 902 
of Rg. 12. In step 1101, the ti-ansmission destination 
table of Fig. 13 is referenced. Upon data transfer to the 
communication confroller 105. tiie host 101 attaches a 
destination ID (804 in Fig. 1 1) to the user data. In step 
1 102, a check is made to see if the attached destination 
ID is already stored in the ti-ansmission destination table 
of Fig. 13. If tiie destination ID is not found in tiie table, 
step 1 104 is reached in which the destination is added 
anew to the table. In step 1 105, the division unit of the 
newly added destination is set to the minimum division 
unit previously defined by the system. Step 1103 is 
reached if tiie destination Is found in the transmission 
destination table. In this step, the division unit corre- 
sponding to the destination ID is retrieved from the 
table. In other words, if tiie destination is already stored 
in the transmission destination table, the coresponding 
stored division unit is used unchanged. Otherwise the 
minimum division unit is set for the newly added desti- 
nation. 

Rg. 15 depicts detailed operations of tiie packet 
transmitting step 904 in Rg. 12. The operations are per- 
formed to transfer data from the communication conti'ol- 
ler 105 to an external network. The instructions involved 
are as follows. 

(1) get_register (STATUS) 

In this process, tiie status of tiie communication 
interface -119 is acquired. If tiie status is normal, the 
transmission processing continues. 

(2) set.register (buf_addr) 

In this process, the first address of tiie transfer data 
1206 in the data memory 121 is written into one of a 
group of control registers 1207 in the communication 
interface 119. 



(3) set_register (pkt Jength) 

In this process, the length of the transfer data 1206 
in tiie data memory 121 is written into a register of the 
5 control register group 1207 in tiie communication inter- 
face 11 9. 

(4) set_register (OUT DMA_GO) 

10 This process is performed by the instruction issued 
to the DM AC 123 of Fig. 1 for data transfer to the buffer 
124. The transferred data has the same lengtii as that 
held in the comrol registers from the first address on. 
The processes above transfer the data 1206 from the 

15 data memory 121 to the buffer 124. In response, the 
communication interface 119 passes the data on to tiie 
ti'ansmitter 126 for packet transmission to the network. 

Rg. 16 indicates the constitution of a sub-ACK 
packet returned for a packet by the receiving side to tiie 

20 transmitting side. The sub-ACK comprises the result of 
transmission 1301, a destination ID 1302 representing 
the destination of transmission, a division flag 1 303 indi- 
cating a division, a packet ID 1304 identifying the 
packet, a division count 1305 indicating the number of 

25 packet divisions, a division ID 1306 indicating tiie post- 
division sequence, and a transmission time 1307 at 
which tiie fransmitting side transmitted tiie packet. The 
result of transmission 1301 shows whether or not tiie 
packet has been normally received. Depending on tiie 

30 transmission result, tiie transmitting side determines 
whether or not to retransmit the packet in question. 

ft should be noted tiiat the destination ID 1 302, divi- 
sion flag 1303, packet ID 1304, division count 1305. 
division ID 1306 and transmission time 1307 are tiie 

35 same as tiiose attached to the data packet sent from tiie 
transmitting side. The attached information of tiie data 
packet is tagged unchanged to the sub-ACK retjrned 
for the data packet. 

Rg. 17 is a flowchart of tiie sub-ACK processing 

40 Step 909 in Fig. 12 for sub-ACK*s of Rg. 16 received by 
the packet transmitting side. In step 1401, a check is 
nnade by referencing the fransmission result 1301 of the 
sub-ACK to see if the divided packet has been normally 
f ansmitted. If tiie packet is found to be normally trans- 

45 mitted. step 1402 Is reached; otherwise step 1406 is 
reached. In step 1406. a reti-ansmlssion request is 
issued to the packet transmitting program of Fig. 12 
(specifically step 904) regarding the abnormally frans- 
mitted packet. Step 904 of Fig. 12 started here is terni- 

50 nated when the packet has been retransmitted. At this 
point, a refransmission count is updated as will be 
desaibed later by referring to Fig. 18 in connection witii 
a sub-ACK control table In step 1 402, the time required 
for tiie f ansmission is calculated. The result of the cal- 

55 culation serves as a parameter for determining an opti- 
mum division unit. The calculation may be perfomied by 
finding the difference between tiie transmission time 
1307 in Rg. 16 and the current time. Specific means for 
knowing tiie time may illustratively be a timer incorpo- 
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rated in the communication controller In step 1403, the 
cun^ent network load is obtained by the communication 
load measuring device 120 of Fig. 1. The communica- 
tion load measuring device 120 Is designed to acquire 
the cun-ent load of the network to which the communica- 5 
tion controller 105 is connected. TTie network load is 
detected by checking to see how many packets have 
been received by the receiver 125 within a unit time. 
TTie load thus acquired serves as a parameter for deter- 
mining an optimum division unit. In step 1404. a check to 
is made to see if the division unit 1002 currently held in 
the transmission destination table (Fig. 13) is appropri- 
ate. The check in step 1404 is made by comparing the 
response time 1003 and communication load 1004 In 
the transmission destination table (Fig. 13) on the one 15 
hand, with the currently acquired response time and 
communication load on the other hand. The division unit 
needs to be updated In two cases: when the current 
communication load is smaller than the communication 
load 1004 held In the transmission destination table 20 
(Fig. 13) and the current response time is smaller than 
the stored response time; or when the current commu- 
nication load is smaller than the communication load 
1004 in the transmission destination table and the cur- 
rently obtained response time is larger than the stored 25 
response time. In the former case, the stored division 
unit Is updated in the fonvard direction of the cun^ently 
obtained division unit. In the latter case, the update Is 
performed in the opposite direction of the currently 
acquired division unit. The updating is executed In step 30 
1405. Specifically where the update is in the fonA^rd 
direction (i.e. +), the stored division unit is enlarged. For 
example, the stored division unit of 2K6 Is replaced by 
4KB. If the update Is in the opposite direction (i.e.. the 
stored division unit is reduced. Illustratively the stored 35 
division unit of 4KB is replaced by 2K6. Such updates 
make it possible to reduce the division unit for long dis- 
tances and to enlarge it for short distances. TTiis is 
because the long-distance transmission takes wore 
time for sub-ACK's to be returned and has a good 40 
response time with the smallest possible division unit. 

Where the retransmission count, to be described 
with reference to Fig. 18, is used as one parameter for 
dividing the packet, the data transfer performance may 
be improved further. This is particularly effective where 45 
many errors are prone to occur during data communica- 
tion with a specific host. When the retransmission count 
is found to inaease, the retransmission time can be 
shortened by reducing the division unit For example, If 
numerous retransmission requests occur with the divi- so 
sion unit of 8KB in effect, the retransmission overhead 
may be lowered by setting a smaller division unit such 
as 4K6. How the retransmission process is can-led out 
will be described later in detail with reference to Rg. 19. 

Below is a description of the network load. The net- ss 
work is not for use by a single user; a plurality of users 
are expected to transfer data concurrently over the net- 
work In such cases, the network load will rise causing 
the response of data transfer to worsen. The deteriora- 
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tion of response is not related to the distance of commu- 
nication. Thus by detecting the network load and using 
it as a parameter for determining the division unit, tiie 
first embodiment of the invention can discriminate those 
variations in response which are not attributable to dis- 
tance. Although the first embodiment has the communi- 
cation load column 1 004 established in the transmission 
destination table (Fig. 13), the column may be replaced 
alternatively by a column for holding communication dis- 
tances. If implemented, the communication distance 
column will allow the division unit 1002 to be obtained 
more accurately The communication distances are to 
be set previously by tiie user for the stored destinations, 
and new destinations may be added to the table and 
matched witii tine correspondingly furnished communi- 
cation distances to ensure higher performance. 

How a plurality of sub-ACK's are awaited will now 
be described with reference to Fig. 18. The process 
involves executing steps 906 and 907 of Fig. 12 to wait 
for the divided sub-ACK's to arrive. Which sub-ACK has 
been received at any given moment is known by use of 
a sub-ACK control table of Fig. 18 established in the 
data memory 121 . Column 1501 accomnnodates packet 
ID'S representing the same contents of the packet ID'S 
212 In the packets 208 of Fig. 2. Likewise, column 1502 
holds division ID s that are the same as the division ID'S 
214 in the packets 208. Each division ID 1502 con-e- 
sponds to a sub-ACK. Information on whetiier or not a 
sub-ACK for a specific division ID 1502 has been 
received Is written to column 1503. If all sub-ACK's are 
found to be returned, tiiat means tiie completion of data 
transfer, which verifies tiie end of step 906. The sub- 
ACK control table is generated upon division of a packet 
(step 902 in Fig. 12). 

Rg, 19 shows that data may be retransmitted at 
high speed when tiie division unit is small. Reference 
numeral 1604 indicates a set of data transmitted in a 
large unit, and 1605 denotes a packet of the same data 
retransmitted. Reference numerals 1606 through 1609 
indicate the data being transmitted In smaller units, and 
1610 stands for one packet of the retransmitted data. In 
many cases where retransmission is requested, only a 
part of the data is erroneous. In such cases, tiie entire 
data must be retransmitted (1605) if the packet Is large 
enough (1604). By contrast. If tiie division unit is small, 
it may take more time to transmit data but the subse- 
quent retransmission thereof will end quickly because 
tiie latter process involves an appreciably low amount of 
data. As a result, tiie overall time for data transfer is 
shortened. 

Rg. 20 is a flowchart of the packet receiving pro- 
gram 1 12 of the communication controller 105 of Fig. 1 . 
In step 1701. a packet is received via the communica- 
tion interface 1 19. In step 1702. a check is made to see 
if the packet has been normally received. If the recep- 
tion of the packet is found to be normal, step 1703 is 
reached; othenvise step 1704 is reached. Whether or 
not the packet is normally received is verified illustra- 
tively by use of a scheme wherein tiie transmitting side 
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attaches parity or cydic redundancy check bits to the 
transmitted data and the receiving side checks the 
attached bits. In step 1703. a sub-ACK indicating the 
norma! reception of data is returned to the transmitting 
side. In step 1704, a sub-ACK indicating an abnormal 5 
receipt of data is returned to the transmitting side. In 
step 1705, a check is made to see if all sub-ACK units 
have been received. The check in step 1705 is accom- 
plished by referring to the division flag 211, packet ID 
212, division count 213 and division ID 214 shown in 
Fig. 2. In step 1706. the tags 210 through 215 in Rg. 2 
are removed from the transmitted data so that only the 
data part is left The removed tags are retained corre- 
sponding to the data and are used in the next step 
(1707). In step 1707, the divided data are merged 
according to the division ID 214. In step 1708, the 
merged data is transferred to the host and the packet 
receiving process is terminated. 

Rg. 21 is a conceptual view indicating how divided 
data are merged. The example of Fig. 21 is one in which 
three packets 1802. 1803 and 1804 are merged. The 
divided data extracted from the three packets are 
merged into one set of data (1805). The initial data. i.e.. 
the data transmitted by the host of the transmitting side 
to the communication controller, is reconstructed by 
merging the divided data in accordance with division 
ID'S 1808. 

Rg. 22 is a conceptual view sketching how the 
invention is applied illustratively to a disk drive an^ange- 
ment. Whereas the description of the invention above 
has centered on data communication between hosts, 
the invention is intended to boost the speed of data 
communication and as such can be applied generally to 
data communication setups including the disk drive 
arrangement. Fig. 22 shows a process in which a com- 
puter 1901 (host) connected to a network 1909 trans- 
mits data 1902 (in the ACK unit for the host) to a disc 
controller 1905 of a disk drive 1904. Reference numeral 

1906 denotes the data received by the disk controller 

1905. The computer 1901 is connected to a communi- 
cation controller 1903. and the disk controller 1905 is 
connected to a communication controller 1907. Tlie 
data 1902 sent from the computer1901 is divided by the 
communication controller 1903 into three sub-ACK unit 
packets 1910. As in the example of Fig. 2, each packet 
1910 comprises divided user data and is furnished with 
tags such as the destination ID. division flag indicating a 
division, packet ID, division count division ID indicating 
the post-division sequence, and transmission time at 
which the packet was transmitted. Upon receipt of the 
packets, the communication controller 1907 removes 
the tags from the packets to reconstruct the initial data 

1906. For data reconstruction, the communication con- 
troller 1907 references the division flag, packet ID, divi- 
sion count, and division ID indicating the post-division 
sequence of each packet as in the case of Fig. 2. For 
each packet received, the communication controller 

1907 returns a sub-ACK 1908 indicating the completion 
of packet transmission. If any one of the three transmit- 



ted packets has developed transmission error, the 
occurrence of the error is written to the sub-ACK 1908 
corresponding to the abnornrtally transmitted packet. In 
response to the sub-ACK. the communication controller 
1903 retransmits only the packet con'esponding to that 
sub-ACK. There is no need to retransmit all packets 
1902 constituting the entire data where any one of the 
packets has developed transmission en-or. When the 
sub-ACK's are returned indicating the normal reception 
of all divided packets by the receiving side, the three 
sub-ACK's are merged into one ACK which notifies the 
host 1901 of the completion of data transmission. 
Because user data is divided into sub-ACK unit packets 
each provided with the division flag, packet ID. division 
count, and division ID indicating the post-division 
sequence ID. the packets are transmitted and received 
Independently and hence in parallel. Where a plurality 
of disk drives 1904 are connected to the disk controller 
1905, the disk controller 1905 may process a plurality of 
disk I/O requests concurrently. This is a significant 
advantage available with the embodimenl of the inven- 
tion allowing the host 1901 to transfer data at high 
speed. Because sub-ACK units are adopted and they 
are merged before transfer to the host computer, i.e., to 
the source of the request, the protocol requirements of 
the first embodiment are the same as those of conven- 
tional communication protocols and thus involve only a 
minimum of modifications in the software of the host 
upon implementation. In addition, the greater the 
amount of transfer data, the more efficient the parallel 
transfer of data carried out for transmission and recep- 
tion with the first embodiment 

Second Embodiment 

Rg. 23 is a block diagram of a software implemen- 
tation of the invention. In Rg. 23. reference numeral 
2001 is a host and 201 1 is a communication controller. 
Working inside the host 2001 are a user program 2002 
and the operating system 2003. The operating system 

2003 includes a communication controlling program 

2004 which in turn comprises a division controlling pro- 
gram 2012, a packet transmitting program 2005 and a 
packet receiving program 2008. The division controlling 
program 2012 incorporates a divided packet transmit- 
ting program 2007 and a divided packet receiving pro- 
gram 2009. A communication request issued by the 
user program 2002 to the network is first received by the 
communication controlling program 2004. Later, control 
is passed on to the division controlling program 2012 
whose detailed working will be described later. The 
packet transmitting program 2005 and packet receiving 
program 2006 are known programs, and the communi- 
cation controller 201 1 is a know device. 

The second embodiment utilizes a conventional 
system when implemented. The packet transmitting 
program 2005 and packet receiving program 2008 deal 
with packets each comprising two major parts, a data 
part 2101 and a packet header part 2102. as shown in 
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Fig. 24. The data part 2101 is provided by the division 
controlling program 2012. Whereas the first embodi- 
ment attaches specific tags to the packet header part, 
the second ennbodinnent cannot modify the packet 
header because it utilizes the existing system. Thus the 
second embodiment attaches to the data part 2101 
those tags (2104 through 2109) that are necessary for 
dividing packets. Besides user data 2103, each packet 
is furnished with such tags as a division flag 2104 indi- 
cating a division, a division count 21 05 representing the 
number of packet divisions, a division ID 21 06 indicating 
the post-division sequence, and a transmission time 
2107 at which the packet was transmitted. 

Fig. 25 is a flowchart of steps showing how the 
divided packet transmitting program 2007 typically oper- 
ates. In step 2201 , the packet is divided into sub- ACK 
units. The details of step 2201 are the same as those of 
the first embodiment in Fig. 14. In step 2202, each of the 
divided sub-ACK unit packets is given the tags 2104 
through 2107 shown in Fig. 24. In step 2203, the sub- 
ACK unit packets are transferred to the destination. In 
step 2204, a check is nnade to see if all sub-ACK units 
have been transmitted. If there exist any sub-ACK unit 
packets yet to be transnnitted, step 2203 is reached 
again and executed. In steps 2205, 2208 and 2206, 
sub-ACK's are awaited for all transmitted packets. 
When sub-ACK's have been received indicating the nor- 
mal reception of all the packets, it is now possible to 
merge the sub-ACK's. This allows the user program 
2202 to remain unaware of the division of the packet. If 
there is a sub-ACK indicating an abnormally transmitted 
packet, that packet alone is retransmitted in step 2208. 
Step 2208 is the same in function as step 909 in Fig. 12. 
When all sub-ACK's have been merged, step 2207 is 
reached in which the user program 2002 is notified of 
the completion of data transfer. 

Fig. 26 is a flowchart of steps of the divided packet 
receiving program 2009. In step 2301, a packet is 
received via the packet receiving program 2006. In step 
2302. a check is made to see if the packet has been nor- 
mally received. If the receipt of the packet is found to be 
normal, step 2303 is reached; othenwise step 2304 is 
reached. In step 2303. a sub-ACK indicating the normal 
reception of data is returned to the transmitting side. In 
step 2304. a sub-ACK indicating an abnormal receipt of 
data is sent back to the transmitting side. In step 2305, 
a check is made to see if all sub-ACK unit data have 
been received. The check in step 2305 is accomplished 
by refen-ing to the division flag 2104, division count 
2105 and division ID 2106 of each packet shown in Fig. 
24. In step 2306, the tags 2104 through 2107 in Fig. 24 
are removed from each packet so that only the data part 
is left. In step 2307, the divided data are merged in 
accordance with the division ID'S 2106. In step 2308. 
the merged data is transferred to the user program 2002 
and execution of the divided packet receiving program is 
2009 terminated. 

Rg. 27 illustrates schematically the principles of 
packet division of the second embodiment. The known 
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packet transmitting program 2005 and packet receiving 
program 2006 are each provided with a plurality of I/O 
ports for communication. The I/O ports are made to cor- 
resporxJ with the destinations of communication on a 

5 one-to-one basis. Because the next packet cannot be 
transmitted through the same port until the nornral 
receipt of the current packet is ascertained by a 
returned ACK. the packet dividing function of the inven- 
tion cannot be implemented using the same port. Thus 

10 the second enrrbodiment has at least two ports (2705. 
2706, 2716. 2717) assigned to each of the communica- 
tion controlling program 2701 of the transmitting side 
and the communication controlling program 2702 of the 
receiving side dealing with one set of user data. In con- 

15 secutive packet transmission, this setup makes it possi- 
ble to transfer the next packet independently of the ACK 
returned for the most recently transmitted packet. The 
division controlling programs 2704 and 2719 transfer 
user data 2703 and 2718 independently through each of 

20 the ports in use 2711 and 2712. It is also possible to 
return sub-ACK's 2713 and 2714 independently through 
each of the ports. With the second embodiment, com- 
munication controllers 2720 and 2719 need only per- 
form conventional operations. Other detailed processes 

25 and the table arangements are the same as those of 
the first embodiment. The second embodiment has the 
advantage of eliminating the need for any modifications 
in the conventional hardware or in the cun-ert operating 
system 2003. 

30 As described, the invention minimizes deterioration 
of the data transfer performance where long distances 
are involved for data communication. 

Claims 

35 

1. A method for transmitting data via a network 
wherein the transmission of a data packet by a 
transmitting side (205(Fig. 2); 1903(Fig-22): 
2704(Fig.27))is acknowledged by an acknowledge- 
40 ment packet returned by a receiving side (206(Rg. 
2): 1907(Fig.22); 2719(ng.27)) before the next 
packet can be transmitted, said transmitting side 
can^ying out the steps of: 

45 (1) dividng each data packet into a plurality of 

data packets; 

(2) furnishing each of the divided data packets 
with an identifier indicating the pre-division 
position in sequence of the data packet in 

50 question; and 

(3) transmitting said divided data packets with- 
out waiting for an acknowledgement packet to 
arrive fa each data packet transmitted; 

said receiving side (206.1907,2719) car- 
55 rying out the steps of: 

(4) merging said divided data packets upon 
receipt in accordance with the identifiers 
thereof; arxJ" 

(5) returning, for each of said divided data 
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packets received, an acknowledgement packet 
provided with receipt infornriation indicating 
wvtiether the data packet In question has been 
normally received. 

2. A method for transmitting data via a network 
according to claim 1. wherein, after the normal 
transmission of all of said divided data packets has 
been verified, one acknowledgement packet is gen- 
erated and returned to the source which requested 
the transfer of the data packet constituted by said 
divkjed data packets. 

3. A method for transmitting data via a network 
according to dalm 2, packet reception Information 
included in said acknowledgment packet Is refer- 
enced In order to retransmit only the packets not 
normally transmitted. 

4. A method for transmitting data via a network 
according to claim 2, further comprising a table for 
matching each of transfer destinations stored 
therein with the unit for data division and a retrans- 
mission count, said packet reception information 
within said acknowledgement packet being refer- 
enced In order to write to the appropriate retrans- 
mission count field of said table the number of times 
data is not normally received by any specific desti- 
nation, wherein, if any one of the stored retransmis- 
sion counts exceeds a predetermined value, the 
con'esponding data division unit is reduced. 

5. A method for transmitting data via a network 
according to claim 3, further comprising a table for 
matching each of transfer destinations stored 
therein with the unit for data division and a trans- 
mission time, said table having a transmission time 
and a network load written therein every time a 
packet is transmitted, wherein, if any one of the 
stored transmission times exceeds a predeter- 
mined value, the corresponding data division unit is 
reduced. 

6. A method for transmitting data via a network 
according to claim 3. wherein said transmitting side, 
having divided a data packet Into a plurality of data 
packets to be transmitted, writes to each of the 
divided data packets the transmission time at which 
the packet in question Is transmitted, wherein said 
receiving side adds said transmission time to an 
acknowledgement packet returned corresponding 
to the received data packet in question, and 
wherein said receiving side receives said acknowl- 
edgement packet and calculates the time required 
to transmit the packet by obtaining the difference 
between said transmission time and the current 
time. 

7. A method for transmitting data via a network 
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according to claim 6, further comprising a table for 
matching each of transfer destinations stored 
tiierein with tiie unit for data division, a transmission 
time and a network load, said table having a tirans- 

5 mission time and a network load written therein 
every time a packet is transmitted, wherein. If trans- 
mitting a packet by use of a large data division unit 
has made the corresponding network load in said 
table less than the current network load while 

10 increasing the corresponding transmission time, 
tiie corresponding data division unit in said table is 
replaced by a larger division unit. 

8. A method for t-ansmltting data via a network 
15 according to claim 1 , wherein, when said network 

comprises two networks having different communi- 
cation paths, said divided data packets are tians- 
fen-ed via one network and said acknowledgement 
packet Is transferred via tfie other network. 

20 

9. A method tor ti^ansmitting data via a network 
according to claim 1 , wherein said data packet Is 
written to a nonvolatile area, wherein, before tiie 
fansmission of said data packet Is completed, a 

25 transmission end notice Is sent to tiie source which 
requested the f ansmission of said data packet, and 
wherein, if tiie fransmlssion of said data packet has 
failed, said data packet is ret-ansmitted by use of 
tiie data held In said nonvolatile area. 

30 

10. A method for fansmitting data via a network 
wherein data is fransfen-ed between a fransmitting 
side (205(Fig. 2); 1903(Fig.22); 2704{Rg.27)) and a 
receiving side (206(Fig. 2): 1907(Fig.22); 

35 2719(Flg.27)); 

said transmitting side (205.1903,2704) dividing 
one set of data into a plurality of sub-data, con- 
structing a plurality of data packets each 
40 including one of said plurality of sub-data, and 

sending said data packets to said transmitting 
side; 

said receiving side (206,1907,2719) receiving 
each of the transmitted packets and returning 

45 to said fransmitting side an acknowledgement 

including a result of reception regarding each 
transmitted data packet; 
said fransmitting side (205.1903.2704) receiv- 
ing said acknowledgement and retransmitting a 

50 data packet corresponding to a received 

acknowledgement which Indicates failure of 
transmission; and 

said receiving side (206,1903,2704) recon- 
structing said one set of data from said sub- 
55 data In said plurality of data packets, after hav- 

ing normally received all packets constituting 
said one set of data. 
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